Grupo sobre escalabilidad en español

Tal y como os comentaba ayer, los últimos días había estado comentando con Marc y Miguel Ángel Pastor la posibilidad de crear un grupo sobre escalabilidad, Hadoop, NoSQL, computación distribuida, etc.

La cosa ha surgido así como de casualidad. Miguel se pone en contacto conmigo preguntándome por listas o grupos sobre el tema; por otra parte, conozco a Marc que me cuenta que le gustaría potenciar la comunidad Hadoop en España, y ya lo demás es el poner en práctica mis habilidades de liante para que entre ellos dos monten un grupo en Google para ver si arranca esta comunidad :)

Elastic Beanstalk: Heroku para Java

Heroku es un servicio online englobado en lo que se conoce como PaaS (Platform as a Service), y que básicamente permite el desplegar aplicaciones Ruby en una nube de servidores que se escala automáticamente para satisfacer las necesidades de carga de las aplicaciones.

En Java (hasta donde yo sé) no había demasiados servicios similares. Está Stax que lo compró Cloudbees me imagino que con la intención de hacer algo similar a Heroku, y estaba por supuesto Google App Engine que es una plataforma que prometía mucho, pero que entre las limitaciones que impone y los problemas que sufrieron muchos desarrolladores por tratarse de una Beta que era una "verdadera Beta", pues no ha tenido toda la popularidad que se podría desear.

Lecciones sobre AWS aprendidas en Netflix

Tal y como escribía hace unos días, la arquitectura de Netflix está basada en Amazon Web Services. La compañía, decidió a principios de año migrar su arquitectura a Amazon.

En el blog de Netflix, comparten cinco lecciones que han extraído de su experiencia al mover su arquitectura desde su propio data center a la nube:

Ofertas de trabajo en Abiquo, Barcelona

Diego Mariño, co-fundador de Abiquo me manda una serie de ofertas para que las publique por aquí, a falta de estar Jobsket listo para empresas :) Tal como anda la cosa es algo raro que alguna empresa busque de golpe más de cinco personas, pero esta empresa está en una fase importante de expansión y puede ser una buena oportunidad si alguien vive o no tiene problemas en mudarse a Barcelona. Además, que no se puede decir que haya muchas empresas innovadoras y donde pueda trabajar en cloud computing en España (¿hay alguna otra?) al tiempo en que compites contras superpotencias como Amazon, IBM, Microsoft, etc. así que seguro que hay emoción.

Os dejo por aquí los enlaces a las mismas por si no conocéis la empresa:

Java Architect

Tasks and responsibilities

* Develop standards and guidelines for the products
* Rollout and train guidelines to development teams
* Coordinate technical decisions
* Review and approve technical designs
* Manage the consistency, integrity and reliability of the architecture
* Advise senior management on current and future technologies
* You will report directly to the Chief Technology Officer



Senior Java Developer

Key Experience:

Core Java, Hibernate, Spring, Web Services, Java Software Engineer/Developer



Java Engineer

Key Experience:

Core Java, Hibernate, Spring, Web Services, Java Software Engineer/Developer.



Senior Flex Developer

We have 2 important opportunities available for highly skilled experienced senior flex/java developers to join the team. You should have more than 2 of years of development experience with Flex (client-side) and Java Developing (server-side) with a smattering of design and usability. It is equally important being formerly a hands on developer.



Virtualization Expert

Key Requirements

* Master’s or Bachelor’s Degree in Computing Science
* VMWARE, XEN, KVM, VirtualBox, Hyper-V (Installation and Administration)
* Storage Systems (OpenStorage, netApp, dell equalogic, etc)
* Network (Virtual Switch, network infrastructure, etc.)
* Programming skills (scripting, JAVA, etc.)
* Excellent communication skills (English & Spanish)



SysAdmin

Tasks and responsibilities

* Coordinate technical decisions
* Review and approve technical designs
* Manage the consistency, integrity and reliability of the architecture
* Advise senior management on current and future technologies
* Give support to the customers
* Maintain multiple services (web server, DNS, etc)
* Maintain and improve development environment
* You will report to the Chief Technology OfficerTasks and responsibilities



QA Test Engineer

* Test requirements and specifications for incorrect or incomplete information, assumptions and conclusions
* Apply that knowledge in the development and implementation of test plans, test objectives and test scheduling
* Organise and carry out functional and non-functional testing within an iterative Scrum-based development environment
* Collaborate closely with developers, product managers and support engineers to correctly identify, prioritise and resolve issues
* Create, review and maintain robust automated regression and data-driven tests
* You will report directly to the Chief Technology Officer

Todos los detalles en el post de su blog. Mucha suerte si os apuntáis.

Los retos de la nube para aplicaciones tradicionales

Muy interesante este hilo en el grupo de Cloud Computing de Google Groups, donde se exponen opiniones sobre cuales son los principales retos a la hora de migrar una aplicación tradicional a un entorno de Cloud Computing como pueda ser Amazon EC2. En el hilo se exponen algunas notas importantes:

• Falta de software preparado para la "nube". ¿Dónde están nuestros cloud-enabled Tomcats, WebSpheres, WebLogics o Jbosses, por decir algo? O por poner un ejemplo más reciente, Google lanza el soporte Java en Google App Engine pero hay que pasarse unas semanas arreglando Groovys, Grails, JRubys y similares.
• Volviendo al tema Google App Engine. La forma de programar cambia. Donde teníamos una base de datos tradicional ahora tenemos BigTable. Encapsulado o no en JPA o cualquier otro interfaz, hay que cambiar el chip.
• Bienvenidos al mundo de la programación distribuida. Aunque se puede usar la nube para desplegar una aplicación en capas tradicional. Pues aquí la idea es la promocionada por BigTables, MapReduces y similares. Es decir, distribuir el procesamiento/almacenamiento/mensajería entre los diferentes componentes de la nube. ¿Estás preparado para ello?, o incluso mejor, ¿Están tus programadores preparados para ello?

Nati Shalom de GigaSpaces comenta este mismo hilo en su blog y también Grig Gheorghiu tiene comentarios interesantes sobre sus experiencias en un despliegue importante sobre EC2.

Esperar fallos parece uno de los consejos más sensatos que se pueden extraer de estas lecturas, y también el de intentar automatizar el proceso para no morir en el intento. Una buena lectura para el que esté planteándose una migración.

Datos históricos, trading y Cloud Computing.

Con el permiso de los que realmente saben de esto ahí va un post sobre Cloud Computing (o quizás debería decir Cloud Storage). Hoy he llegado hasta un artículo en WallStreet Technology que me ha parecido super interesante, al tiempo que me ha traido a la mente experiencias pasadas en mi primer trabajo aquí en Irlanda.

Uno de los retos más importantes que tiene cualquier aplicación de trading que se precie es la de permitir el análisis técnico de los instrumentos que presenta a sus usuarios. El inmenso volumen de datos que hay que manejar convierte el almacenamiento de estos datos en un factor muy importante a la hora de diseñar un sistema de este tipo. Y aunque existen algunas técnicas y bases de datos para disminuir el volumen de datos almacenados, según la exactitud de datos que necesites éstas no pueden ser aplicables.

Por poneros un ejemplo, en un sistema de divisas donde a lo mejor trabajas con 32 pares (eur-usd, usd-jpy, ...) puedes encontrarte con que las divisas más comunes cambian unas 16 veces por segundo, lo que nos da 960 valores por minuto, 57600 valores en una hora, y si asumimos una ventana de 8 horas para trading pues tenemos casi medio millón de valores. En fin, esto no es nada si lo comparamos con un mercado de valores como el NASDAQ o el FTSE donde hay muchos más valores.

Estos mercados además por sus características tienen unos requisitos regulatorios mucho más estrictos de los que pudiesemos haber tenido nosotros, ya que tienen la obligación de mantener durante largos períodos de tiempo el histórico de todos los valores del índice y de las operaciones que se han realizado, ya que estos datos pueden ser necesario para resolver reclamaciones, pleitos y todas estas cosas, así que por ley se ven obligados a mantener absolutamente todo.

El lugar más obvio para almacenar esta información es una base de datos, o un sistema de ficheros, que periódicamente se vuelca a DVDs o cintas de backup. Pero, y ya que dicen que está de moda, ¿por qué no almacenarlo en la nube? El artículo en cuestión con el que empezaba este post habla sobre como a Claude Courbois, associate VP, product development, de Nasdaq Data Products se le ocurrió el utilizar los servicios de Amazon S3 para uno de sus productos, Market Replay. El producto en si mismo ya es interesante, y básicamente consiste en ofrecerle una herramienta a los clientes de Nasdaq para que puedan reproducir una operación ejecutada en el pasado. Es como la máquina del tiempo del índice NASDAQ, y a los clientes les puede resultar enormemente útil si reciben cualquier tipo de reclamación ya que pueden demostrar que la operación ha sido legítima (o no).



Así, según parece Nasdaq está añadiendo diariamente entre 30 y 80Gb de datos a S3 en forma de 300.000 ficheros de datos, conteniendo cada fichero el equivalente a 10 minutos de actividad en el índice para un instrumento dado. La recuperación de datos desde S3 lleva menos de un segundo y con la ventaja adicional de que el sistema aprovecha "la nube" para escalar. Los clientes reciben la información instantáneamente sin tener que esperar a que se recupere de los sistemas de backup.

Otro factor muy importante que se menciona en el artículo y que parece que las empresas comienzan a entender es que durante el todo el desarrollo del producto no se ha pagado ni un céntimo extra por lo que no se utiliza. En un inicio Courbois comenta que recibieron facturas de tan sólo 5 dólares y no se vio obligado a gastarse 20000 dólares en hardware o realizar ningún megacontrato con alguna proovedora de servicios. Muy importante lo que comenta y que quizás en estos tiempos que corren sea más sencillo que a algunos les pueda entrar por la cabeza:

"Even though we're in a big company, every new project is a start-up, and you want to avoid situations where you have to plunk down a bunch of money to move forward."

El artículo también trata brevemente temas más polémicos como la seguridad y el soporte. Mi opinión personal es que ahí hay realmente mucho que hacer todavía, pero también hay mucho negocio, y compañías como RightScale no harán más que crecer y ganar mercado en los próximos años.

Dos blogs sobre escalabilidad en español

Desde hace semanas vengo siguiendo un par de blogs muy interesantes que se centran en el tema de la escalabilidad de una manera directa o indirecta.

Por una parte está Nubeblog, que viene posteando bastante frecuentemente sobre el tema de cloud computing y todo lo relacionado. Por otra parte tenemos el blog de Diego Mariño, CEO de abiquo, Externalidades que mezcla temas de emprendedores y Grid Computing, lo que lo hace doblemente interesante.

Este blog es muy modesto como para que vaya a crear un "efecto pensamientos ágiles", pero personalmente no conozco muchos más blogs en castellano dedicados a este tipo de temas, así que merece la pena mencionarlos. Yo estoy enganchado a sus posts así que si los desconocíais, quizás alguno los encuentre también interesantes.

Por cierto, ¿alguna otra recomendación en castellano sobre estos temas?

Amazon reacciona. Habrá por fin almacenamiento persistente para EC2

Google lanza Google App Engine la pasada semana y todo el mundo se vuelve loco y ruegan que soporten sus lenguajes. Estaba claro que esto era un golpe importante para Amazon ya que parte de su base de usuarios irremediablemente se fugará a un servicio como el de Google, que es gratuito.

Amazon tenía que reaccionar. Y parece que lo ha hecho, aunque por ahora únicamente en forma de anuncio. Werner Vogels anunciaba ayer en su blog que Amazon ofrecerá en breve almacenamiento persistente como parte de sus servicios. La nueva funcionalidad permitirá crear volúmenes de almacenamiento persistente que variarán desde 1Gb hasta 1Tb de datos. Los volúmenes se podrán montar en cualquier instancia de EC2 y básicamente se comportarán como discos sin formato sobre los que se podrá instalar cualquier sistema de ficheros. Los volúmenes serán accesibles localmente dentro la zona de accesibilidad sobre la que hayan sido desplegados.

A mayores de esto, Amazon también ofrecerá la posibilidad de crear snapshots de modo que se pueda almacenar una imagen de cualquier sistema de ficheros en Amazon S3. La idea es que esto puede servir para replicar el sistema de ficheros en múltiples zonas de accesibilidad para construir aplicaciones geo-scalables. En el blog de Amazon Web Services ofrecen más información sobre el nuevo almacenamiento persistente para EC2.

Amazon anunció el pasado mes el lanzamiento de zonas de disponibilidad y IPs elásticas. Ahora reacciona con almacenamiento persistente para EC2. Y es que está claro que no hay nada como tener algo de competencia para dinamizar el mercado. Al final creo que los beneficiados somos nosotros, y la verdad es que ya dan ganas de que entren más compañías como Google en serio en el mercado del cloud computing.

¿Cuál será el próximo lenguaje soportado por Google App Engine?

Sin duda, la noticia de la semana es Google App Engine. Con todo lo que se ha hablado sobre esta iniciativa, poco más se puede añadir. En inglés probablemente la mejor revisión es la de InfoQ, y en español me quedo con la de Aitor.

Lo que me ha hecho gracia hoy es que visitando diferentes foros, parece que hay una guerra entre los fans de Ruby y los fans de Java para intentar presionar por ser el siguiente lenguaje en ser soportado por Google. Y es que está bastante claro que si Google ofrece hosting gratuito en forma de cloud para cualquiera de estas plataformas, cualquiera de ellas cogerá una enorme tracción. Mientras escribo esto, Ruby tiene 87 puntos y Java 83, así que la pelea está bastante apretada.

Así que Javeros y Raileros, hagan sus votos. Eso sí, en la lista de peticiones para lenguajes, por ahora gana Perl :-).

Amazon mejora su oferta de cloud computing con IPs estáticas y múltiples datacenter

Ayer estuve leyendo las novedades que ha añadido Amazon a su oferta de cloud computing y la verdad es que cada vez resulta realmente más atractiva.

Parece que lo primero que han hecho es añadir IPs estáticas; o bueno más correctamente lo que ellos denominan IPs elásticas, que sería como una IP estática pero asociada con una cuenta de usuario. De modo que un usuario no puede tener más de cinco IPs elásticas pero que las puede manejar a su antojo dándolas de alta, de baja, asociándolas a diferentes instancias en diferentes momentos, etc. En el blog de RightScale presentan un muy buen ejemplo de como utilizar estas nuevas IPs.

La segunda novedad es que ahora es posible disponer de servidores en múltiples localizaciones, gracias a lo que Amazon llama availability zones. Así pues, ahora amazon permite reservar instancias en diferentes regiones que pueden estar en diferentes países y continentes, y a su vez dentro de cada región se pueden seleccionar diferentes availability zones. Cada availability zone, garantiza su independencia de las otras zonas dentro de la misma región, de modo que si existe un desastre en una de las zonas, la otra todavía seguirá activa. Nuevamente en el blog de RightScale tienen un ejemplo fenomenal sobre como utilizar esta funcionalidad.

Se ve que Amazon se está espabilando a raíz de los últimos movimientos en el mercado. ¡Si es que no hay nada como la competencia!

IBM abrirá un centro de cloud computing en Dublin

Noticia portada en los periódicos tanto online como impresos por estas zonas. Resulta que IBM abrirá el primer centro europeo de cloud computing en Dublin. Según se comenta en la noticia que enlazo, parece que IBM dará trabajo a 21 personas y basará su tecnología en software Open Source.

Hace poco ya comentaba que Sun se preparaba para competir con Amazon. Y la verdad es que parece que esto se está convirtiendo en una moda ya que hace unos días HP lanzaba su plataforma de cloud computing y parece que pronto lo hará Microsoft.

Está claro claro que los vendedores de servidores tienen que ponerse las pilas para entrar en un mercado ahora mismo dominado por Amazon y lleno de pequeños proveedores. A medida que pasan los meses cada vez son más empresas las que se apuntan a la moda del cloud computing y que ahorran costes, y dolores de cabeza, utilizando centros de computación virtuales, que además de ser bastante baratos son mucho más sencillos de administrar y, por qué no, proponen un modelo de computación mucho más limpio.

La verdad es que la cosa se pone la mar de interesante en este frente.

¿Es EC2 la solución para los tests de carga?

Observando las noticias que se van sucediendo relacionadas con el mundo de los servidores, parece que una tendencia últimamente es el utilizar instancias grandes de Amazon EC2 para realizar los tests de stress.

Y es que la idea es realmente atractiva. ¿Para qué molestarse en comprar o alquilar servidores y generar miles de clientes simulados en los mismos si por un módico precio puedes aprovechar la estructura de Amazon para ello? Es más, si el proceso de test de stress se realiza, digamos una vez al mes, pues una razón más para llevarse ese servicio a EC2 ya que la facturación es por hora de uso.

Aunque esto parecería algo dirigido especialmente a startups, parece que en Oracle es lo que están haciendo para probar Coherence y también en Webtide para probar su servidor de aplicaciones Jetty.

Está claro que el concepto de cloud computing está cambiando poco a poco la forma de trabajar de las empresas. ¿Cuánto tardarán los grandes vendedores de hierro en ofrecer servicios similares? Porque Microsoft y Google tienen este sector en el punto de mira, y tarde o temprano la popularidad de estos servicios tiene que ir haciendo mella en la facturación de las compañías que nos venden servidores físicos. Seguramente tendremos que esperar un par de años para verlo.

(foto de midom@flickr)

Grid vs. Spaces; Oracle Coherence vs. GigaSpaces

Ambos, Oracle Coherence y GigaSpaces, son dos de los productos más utilizados en el mundo de las finanzas, en especial en el ámbito de trading (equities, derivatives, funds, fx, ...). Ambos comparten la idea de poner los datos lo más cerca de la aplicación de manera que sea posible para minimizar la latencia asociada a la obtención de los mismos (i.e. acceder a base de datos, a un servicio remoto, etc.). Sin embargo, el transfondo e historia de ambos productos es diferente y merece la pena echarles un vistazo.

Por una parte Oracle Coherence es un producto que creó la compañía Tangosol adquirida por Oracle este mismo año. La compañía fue fundada en el 2000 por Cameron Purdy, alguien que desde siempre ha sido un asiduo participante en los foros más conocidos del sector, y que en su momento localizó una necesidad en el mundo de J2EE ante los problemas técnicos que presentaban tecnologías como EJB. En su momento fue también el principal impulsor del JSR-107 (JCache), JSR que siempre ha estado demasiado parado (muchos culpan al propio Cameron).

Por otra parte, GigaSpaces ha seguido siempre un camino paralelo y muy similar. Fundada tambiéen en el año 2000 por Nati Shalom se trata de un producto que inicialmente estaba orientado al mundo de Jini, posteriormente JavaSpaces; mundo en el que por cierto se ha convertido en una referencia.

Oracle Coherence es lo que ellos denominan memory "distributed data grid solution", vamos que es una cache distribuida. Estas caches se "pegan" a nuestros componentes y les sirven de cache de modo que no sea necesario acceder a una base de datos o cualquier otro servicio para obtener estos datos. Por detrás existe un complejo protocolo de comunicación para asegurarse que los datos siempre permanecen consistentes, que todo está sincronizado, y que siempre existen copias disponibles para garantizar la disponibilidad. Todo esto sin afectar realmente a la arquitectura de nuestras aplicaciones.

Por su parte, GigaSpaces sigue un camino mucho más rádical y propone que el tradicional modelo basado en capas es erróneo y no apto para sistemas escalables. El problema que plantean es que a la hora de escalar una aplicación empresarial es necesario escalar todas las capas (web, appserver, base de datos, ...), lo que se hace muy complicado. En su lugar proponen el despliegue de aplicaciones en lo que se llaman espacios. VMs dedicadas que contienen todas las capas en una misma VM y que no requieren ningún tipo de acceso externo (salvo quizás para persistir asíncronamente los datos). De este modo se minimiza enormemente la latencia y se consigue una escalabilidad lineal simplemente desplegando nuevas VMs. Para garantizar la disponibilidad se despliegan diferentes espacios y se sincronizan los datos entre los mismos.

Todo esto que comento aquí viene mucho mejor explicado en dos presentaciones que Niti Shalom y Cameron Purdy realizaron en la Spring One 2007. Ambas presentaciones están disponibles en Parleys y dejo los enlaces a continuación. Son realmente recomendable si os gustan estos temas.

Coherence an Introduction
Scalable as Google Simple as Spring (quizás un título no muy apropiado para la charla de GigaSpaces).